Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-092.TXT

Text File | 1992-06-30 | 40.1 KB | 1,073 lines

C.S.M.P. Digest             Sun, 24 May 92       Volume 1 : Issue 92

Today's Topics:

    Time-out for Network Apps
    Getting a path from an Alias
    High-speed serial communications on Mac
    Anyone know about this trap?
    comp.sys.mac.programmer.OOP
    Quickdraw to ASCII printer
    Need help with Finder AppleEvents...


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Jonathan R Schultz)
Subject: Time-out for Network Apps
Organization: Iowa State University, Ames IA
Date: Mon, 20 Apr 1992 18:31:59 GMT

I am using a commercial network application (kept anonymous intentionally).
The server will log-off a terminal if the user leaves a dialog box
(print, save, etc...) open for more than 90 seconds. ADSP is being used, so
I looked at the documentation and found out that there is a 90 second time-out
"feature".

I contacted the company about this, but their response implied nothing could be
done. Is this true, or is it just difficult? Any explanation or reference to
documentation would be helpful.

Thanks!

- --

Jonathan Schultz
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 23 Apr 92 02:42:46 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jonathan R Schultz) writes:
> I am using a commercial network application (kept anonymous intentionally).
> The server will log-off a terminal if the user leaves a dialog box
> (print, save, etc...) open for more than 90 seconds. ADSP is being used, so
> I looked at the documentation and found out that there is a 90 second time-out
> "feature".
>
> I contacted the company about this, but their response implied nothing could be
> done. Is this true, or is it just difficult? Any explanation or reference to
> documentation would be helpful.

Sure there are ways to make programs work even when dialogs are up.
The programmer has to know something about using FilterProcs.  You
just check the io flags when there is idle time and call the appropriate
routines from there.

- --  Michael Peirce         --   [e-mail]
- --  Peirce Software        --   Suite 301, 719 Hibiscus Place
- --  Macintosh Programming  --   San Jose, California USA 95117
- --           & Consulting  --   voice: [phone] fax: [phone]
- --                         --   AppleLink: peirce & America Online: AFC Peirce

---------------------------

From: Adrian C Ruigrok
Subject: Getting a path from an Alias
Date: 21 Apr 92 18:13:21 GMT
Organization: Bell-Northern Research

I have a nice little alias record and I want to grope from that a text path to
the file.  However there seems to be a bit of a problem

I use GetAliasInfo passing an index of -1, 0, 1, ... and I find something
really odd.  The results are EXACTLY the same for the target being

a) Macintosh HD:     - the root level hard drive and that is it....
b) Macintosh HD:Macintosh HD:  - a folder with the same name as the hard drive
in the root level.

The call also does not seem to do what the documentation suggests it should do.
 It claims you can just happily go through the indexes from 0, 1, 2, and so on
and when you run out of parents it will return null.  Well it seems to not
bother telling you about the volume so you have to somehow figure out whether
or not to tack on the volume name.

This should be easier than it seems to me!  Anyone have any insight into how
this call works?  Am I doing something completely off base or is the call
documented completely wrong?

Adrian
- ------------------------------
Adrian C Ruigrok
Bell-Northern Research
Ottawa, Canada
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 23 Apr 92 17:05:47 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, Adrian C Ruigrok writes:
> I have a nice little alias record and I want to grope from that a text path to
> the file.  However there seems to be a bit of a problem

[description of problem omitted]

I've looked at "alis" resources with ResEdit, and they do indeed seem to have
the full pathname in them. Nevertheless, there is no Alias Manager call for
returning this information.

On the other hand, why bother? Why not just call ResolveAlias and expand
the FSSpec that it returns?

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
Happy Birthday Bill--328 today!

---------------------------

From: [e-mail] (Bradley Green )
Subject: High-speed serial communications on Mac
Date: 8 Apr 92 17:55:51 GMT
Organization: University of Pennsylvania

I would like to use the serial port on the Mac at LocalTalk data rates,
i.e. 232Kbaud, without using LocalTalk/AppleTalk protocols.  In other
words, I just want to be able to send straight data at these speeds.  I
understand that the serial driver does not support speeds over 34Kbaud or
so.

My question is this:  Do any of you out there know a source for the
direct hardware calls I need to do this?  Or, even better, a source for
prewritten (public domain) code?  Thanks for your help

Brad

+++++++++++++++++++++++++++

From: [e-mail] (Thomas R. Kimpton)
Organization: Digital Technology, International
Date: Wed, 22 Apr 92 18:00:47 GMT

In article <[e-mail]> [e-mail] (Bradley Green ) writes:
>I would like to use the serial port on the Mac at LocalTalk data rates,
>i.e. 232Kbaud, without using LocalTalk/AppleTalk protocols.  In other
>words, I just want to be able to send straight data at these speeds.  I
>understand that the serial driver does not support speeds over 34Kbaud or
>so.
>

I haven't done precisely this but have done stuff using non-"standard"
data rates (MIDI).  If you can't get code that already does it
you'll need to get a copy of the Zilog 8530 SCC manual.  You don't
need assembly per se, it can be done in C easily enough.  Though
I wouldn't want to do it in pascal.  Programming the SCC (Serial
Communications Controller) is done by selecting on chip registers
by writing to a memory location, then writing the data (I think
to another location, but it's been years).  Reading the chip
is done similarly.  The SCC has an on-board clock used to create
the data rate by programming an on-board divider.  The constants
in Serial.h (300baud etc.) are exactly these constants. You
need to look in the manual to see how to derive a constant for
234 KBaud.  Also you will need to read/write the SCC:
  234000/ (5/6/7/8 data + 1 start + 1/1.5/2 stop + 0/1 parity)
times per second ( 8/1/1/0 = 23.4K = every .0000427 seconds).

The SCC does have an on chip FIFO, but I don't remember how deep
it is.

Hmm... looks like you're in for some "fun" times. Good luck.
I wonder how Apple manages to run at these rates?

- --
- ---
Tom Kimpton                            [e-mail]
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 22 Apr 92 21:38:18 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.uucp> [e-mail] (Thomas R. Kimpton) writes:

   data rates (MIDI).  If you can't get code that already does it
   you'll need to get a copy of the Zilog 8530 SCC manual.  You don't
   need assembly per se, it can be done in C easily enough.  Though
   I wouldn't want to do it in pascal.  Programming the SCC (Serial
   Communications Controller) is done by selecting on chip registers
   by writing to a memory location, then writing the data (I think
   to another location, but it's been years).  Reading the chip
   is done similarly.  The SCC has an on-board clock used to create

This, of course, breaks on IIfx and Quadra 900, unless you use the
Serial Port Compatibility cdev...

   The SCC does have an on chip FIFO, but I don't remember how deep
   it is.

Between two and four bytes.

   Hmm... looks like you're in for some "fun" times. Good luck.
   I wonder how Apple manages to run at these rates?

If a byte comes in, it generates an interrupt. Using normal serial
port drivers, each incoming byte is placed in a buffer using an
interrupt. However, LocalTalk code makes the interrupt routine
loop and poll the port until there is no more packet data on the
first interrupt, effectuvely servicing the entire packet with one
interrupt. Or, why macs are so slow when running LocalTalk...
(Unless you have a IIfx or Q900 in non-compatible mode, see above)

- --
"You should meet yourself someday. I'm sure you would hate it."
- - Me: [e-mail]; Jon W{tte (The Diplomat - NOT!)

+++++++++++++++++++++++++++

From: [e-mail]
Organization: Actrix Information Exchange
Date: Thu, 23 Apr 1992 04:59:28 GMT

In article <[e-mail]> [e-mail] (Thomas R. Kimpton) writes:
> The constants
> in Serial.h (300baud etc.) are exactly these constants. You
> need to look in the manual to see how to derive a constant for
> 234 KBaud.

Sorry -- the constant for 56K is zero, the smallest possible.

- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"

---------------------------

From: [e-mail] (Bill S. Goldman)
Subject: Anyone know about this trap?
Date: Tue, 14 Apr 92 19:33:10 GMT
Organization: University of New Mexico, Albuquerque

I was poking around and found a program that calls trap AC14.  I
couldn't find any references to it in IM or the technotes.  Does
anyone know what it's supposed to do?  Please mail me because it's
not of general interest.  Thanks.


                    Bill Goldman
                    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 15 Apr 92 05:22:24 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Bill S. Goldman) writes:
> I was poking around and found a program that calls trap AC14.  I
> couldn't find any references to it in IM or the technotes.  Does
> anyone know what it's supposed to do?  Please mail me because it's
> not of general interest.  Thanks.

<interrupt>
NMI
dh ac14
Disassembling hex value
    007DAD72   _SetFractEnable ,AutoPop          ; AC14          | AC14

You owe the Oracle an enhancement that lets me copy-and-paste text
from a MacsBug screen.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 18 Apr 92 20:50:12 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Lawrence
D'Oliveiro, Waikato University) writes:
> In article <[e-mail]>, [e-mail] (Bill S. Goldman)
writes:
> > I was poking around and found a program that calls trap AC14.  I
> > couldn't find any references to it in IM or the technotes.  Does
> > anyone know what it's supposed to do?  Please mail me because it's
> > not of general interest.  Thanks.
>
> <interrupt>
> NMI
> dh ac14
> Disassembling hex value
>     007DAD72   _SetFractEnable ,AutoPop          ; AC14          | AC14

> You owe the Oracle an enhancement that lets me copy-and-paste text
> from a MacsBug screen.

The MacHack-91 collection has an MPW tool which gets input from
MacsBug. Pretty cool.

Cheers,
Kent, Dynamic phone answering maniac

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Tue, 21 Apr 1992 02:12:55 GMT

In article <[e-mail]>, [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
> You owe the Oracle an enhancement that lets me copy-and-paste text
> from a MacsBug screen.

And a mouse cursor on the MacsBug screen so that my colleagues and
I can discuss the results of our latest debugging session without getting
grotty fingerprints on the monitor screen (-:

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Life without ResEdit and MacsBug is too horrible to comprehend.


---------------------------

From: [e-mail] (Daryl Spitzer)
Subject: comp.sys.mac.programmer.OOP
Date: 15 Apr 92 00:41:29 GMT
Organization: MIND LINK! - British Columbia, Canada

> ..or comp.sys.mac.programmer.OOP which would contain most of the
> object oriented frameworks and languages. We had this discussion before,
> is it time to split the mac programming group to sub-groups or not?

This is a good idea.  The TCL mailing list is seeing a great deal of use, so
I'm sure this would as well.
- --
- -------------------------------------------------------------------
 [e-mail]     "Life isn't just, life just is."
         [e-mail]              -- Me  (I think.)
       [e-mail]
- -------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Bradley Green )
Date: 15 Apr 92 01:09:17 GMT
Organization: University of Pennsylvania

In article <[e-mail]> [e-mail] (Daryl Spitzer) writes:
>> ..or comp.sys.mac.programmer.OOP which would contain most of the
>> object oriented frameworks and languages. We had this discussion before,
>> is it time to split the mac programming group to sub-groups or not?
>
>This is a good idea.  The TCL mailing list is seeing a great deal of use, so
>I'm sure this would as well.

I couldn't agree more.  If I miss reading the group for a day or two, there
are so many articles that I usually have to just skip them all.  Splitting
the group into several subgroups would allow us all to prescreen our reading
material more effectively

- --
- ------------------------------------------------------------------------------
* Bradley S. Green                University of Pennsylvania   *
* [e-mail]            [phone]             *
*                                         *

+++++++++++++++++++++++++++

From: [e-mail] (Charlie Reiman)
Date: 15 Apr 92 03:22:08 GMT
Organization: University of Illinois at Urbana

[e-mail] (Bradley Green ) writes:

>In article <[e-mail]> [e-mail] (Daryl Spitzer) writes:
>>> ..or comp.sys.mac.programmer.OOP which would contain most of the
>>> object oriented frameworks and languages. We had this discussion before,
>>> is it time to split the mac programming group to sub-groups or not?
>>
>>This is a good idea.  The TCL mailing list is seeing a great deal of use, so
>>I'm sure this would as well.

>I couldn't agree more.  If I miss reading the group for a day or two, there
>are so many articles that I usually have to just skip them all.  Splitting
>the group into several subgroups would allow us all to prescreen our reading
>material more effectively

Although I know this is a lost cause, I am opposed to a new group.  If
I have something to say regarding MacTCP, I always have to scratch my
head and ask "c.s.m.p or c.s.m.c?" Now, if I have a questions regarding
the toolbox, but my program happens to be written in C++, then where
should I go?

Other points again a .oop group:
1) .oop is very broad. Folks that use MacApp aren't interested in TCL stuff,
   and visa versa. In other words, you would still have lots of useless
   messages to wade through.

2) Wanton subdivision of newsgroups is getting tedious. Consider how many
   mac newsgropus there already are:

   comp.sys.mac.announce
   comp.sys.mac.apps
   comp.sys.mac.comm
   comp.sys.mac.databases
   comp.sys.mac.digest
   comp.sys.mac.games
   comp.sys.mac.hardware
   comp.sys.mac.hypercard
   comp.sys.mac.misc
   comp.sys.mac.programmer
   comp.sys.mac.system
   comp.sys.mac.wanted

   Consider how many sun groups there are:

   comp.sys.sun.admin
   comp.sys.sun.announce
   comp.sys.sun.apps
   comp.sys.sun.hardware
   comp.sys.sun.misc
   comp.sys.sun.wanted

   And how many ibm.pc groups:

   comp.sys.ibm.pc.digest
   comp.sys.ibm.pc.hardware
   comp.sys.ibm.pc.misc

   Draw you own conclusions.

3) Why stop there? Why not:

   comp.sys.mac.programmer.basic
   comp.sys.mac.programmer.fortran
   comp.sys.mac.programmer.oop.cobol
   comp.sys.mac.programmer.oop.asm
   comp.sys.mac.programmer.68k.micro-code
   comp.sys.mac.programmer.fine-art-of-trap-patching
   comp.sys.mac.programmer.spinning-beach-ball
   comp.sys.mac.programmer.easter-eggs

   ...etc...

Before, I said stopping the creation of a new group is a lost cause.
This is because I have yet to witness a newgroup fail to be created.
Folks tell me this has happened but I haven't seen it yet. Perhaps this
will be a first for me.

Consider me an avowed "no" vote, if/when you actually decide to go
through with all the formal pomp and circumstance.

The preceeding text wasn't meant to be infammatory, so please leave your
matches in the kitchen.

- --
Charlie Reiman - [e-mail]
"People are going to take to voice input like lemmings to the sea."
                     -Tony Bove (MacWeek V.6 N.13)

+++++++++++++++++++++++++++

From: [e-mail] (John Andrews)
Organization: UIUC Center for Supercomputing Research and Development
Date: Wed, 15 Apr 92 13:59:40 GMT

[e-mail] (Charlie Reiman) writes:

>Although I know this is a lost cause, I am opposed to a new group.  If
>I have something to say regarding MacTCP, I always have to scratch my
>head and ask "c.s.m.p or c.s.m.c?" Now, if I have a questions regarding
>the toolbox, but my program happens to be written in C++, then where
>should I go?
> [other comments deleted]
>--
>Charlie Reiman - [e-mail]
>"People are going to take to voice input like lemmings to the sea."
>                     -Tony Bove (MacWeek V.6 N.13)

I am also against the proposed subdivision of c.s.m.p .  There are enough
mac newsgroups already.

- --
John Andrews ([e-mail]) "He who dies with the shortest .sig, wins"
Graduate Research Assistant, Center for Supercomputing R&D, Urbana, IL

+++++++++++++++++++++++++++

From: [e-mail] (Eric W. Sink)
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 15 Apr 1992 14:40:36 GMT

In <[e-mail]> [e-mail] (John Andrews) writes:

>I am also against the proposed subdivision of c.s.m.p .  There are enough
>mac newsgroups already.

Me too.  Besides, I thought c.s.m.p already WAS
comp.sys.mac.programmer.oop ! :-)

I'd certainly like to see more TCL/MacApp traffic.  More TCL is great
because I use it.  More MacApp would be great because I know so little about
it.  About all I ever see on MacApp is the periodic mention of the fact
that it requires a Quadra 900 with 64 meg RAM and 1 gig disk just to
compile hello world (paraphrased from Mark Lanett).

I'll say this : if it comes to a vote, I'll vote no.  If it passes
anyway, I'll read all the new groups.

- --
Eric W. Sink, USACERL         | The essence of GUI programming : "What
Box 9005, Champaign, IL       | started out as a half hour hack has been
61826-9005 1-800-USA-CERLx449 | bothering me for two weeks now." -- Matt Mora
- ---- [e-mail] ---------|

+++++++++++++++++++++++++++

From: [e-mail] (OverLord of Underlings)
Date: 17 Apr 92 17:22:33 GMT
Organization: Western Washington University

well I'm all for it...
I'd much rather have the control I have with nn or rn then having everything
dumped into my mailbox...

Count me in

- --
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RWD
_O_  Ryan Walker Davis >> The HeadHunter >> OverLord of Underlings
 |   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 18 Apr 92 00:32:56 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Bradley Green
) writes:
>
> In article <[e-mail]> [e-mail] (Daryl Spitzer)
writes:
> >> ..or comp.sys.mac.programmer.OOP which would contain most of the
> >> object oriented frameworks and languages. We had this discussion before,
> >> is it time to split the mac programming group to sub-groups or not?
> >
> >This is a good idea.  The TCL mailing list is seeing a great deal of use, so
> >I'm sure this would as well.
>
> I couldn't agree more.  If I miss reading the group for a day or two, there
> are so many articles that I usually have to just skip them all.  Splitting
> the group into several subgroups would allow us all to prescreen our reading
> material more effectively

De ja vu, here's the suggestion I presented some time ago, modelled after
the DTS groups :-) :

(
(platforms & tools (includes OOP and compiler/language issues))
)hardware&os       (we are talking about drivers, mem and low level
programming))
(n&c               (networking)
(printing&graphics (quickdraw, printing, imaging, quicktime))
(toolbox           (inits, WDEFs, toolbox APIs)
)

Any other ideas?

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 19 Apr 92 18:14:41 GMT

>> In article <[e-mail]> [e-mail] (Daryl Spitzer)
>>
>> I couldn't agree more.  If I miss reading the group for a day or two, there
>> are so many articles that I usually have to just skip them all.  Splitting
>> the group into several subgroups would allow us all to prescreen our reading
>> material more effectively

I concur!  Right now I'm reading 312 posts simply because I haven't had
time to read this group since Thursday.  I would vote to subdivide this
group because it probably wouldn't add to the volume of postings, yet it
would certainly organize them according to interest better.


[Kent Sandvik gives list of possible c.s.m.p subdivisions]
>Any other ideas?

comp.sys.mac.programmer.wizards.  If someone asked here what his app
should do while it's tracking the mouse, he would get singed (lightly
flamed) and told to take it to comp.sys.mac.programmer or equivalent.
This is where to go to ask for ideas on what to patch to get something
drawn on the desktop whenever an update is needed, clipped behind all
windows and other low level, skanky-hack stuff.  I guess if Kent's ideas
go through, this would be closest to his Hardware&OS group.  csmpw would
be more general, and more advanced.  If it worked for Unix, it could work
for csmp...

Nevertheless, I really like the idea of organizing this hierarchy better.
If we figure out what we need by discussion here and it achieves popular
appeal, it shouldn't be too hard to get the CFV to pass.

I would kind of like to see a comp.sys.mac.programmer.newbie, but I'm
afraid nobody would read it...


    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Organization: University of Illinois at Urbana
Date: Sun, 19 Apr 1992 19:36:04 GMT

[e-mail] (Scott Bronson) writes:

>I concur!  Right now I'm reading 312 posts simply because I haven't had
>time to read this group since Thursday.  I would vote to subdivide this

I suggest you switch to a more modern newsreader than rn. Maybe nn.

>comp.sys.mac.programmer.wizards.  If someone asked here what his app
[...]
>be more general, and more advanced.  If it worked for Unix, it could work
>for csmp...

But it doesn't work for unix. Nobody reads the group. c.s.m.p.wizards was
hashed out here a while ago, and died because it's a worthless idea. Maybe
you're new here.
- --
Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 19 Apr 92 22:18:58 GMT

In <[e-mail]> [e-mail] (Mark Lanett) writes:

>[e-mail] (Scott Bronson) writes:

>>I concur!  Right now I'm reading 312 posts simply because I haven't had
>>time to read this group since Thursday.  I would vote to subdivide this

>I suggest you switch to a more modern newsreader than rn. Maybe nn.

I use nn.  Too bad hardly anybody bothers to put good descriptive subject
lines in their messages.  I usually just hilite all, then go through and
remove the messages that I know that I don't want to read.  Wouldn't you
agree that most of the manual work of selecting articles could be overcome
by pre-sorting articles into their own newsgroups?

>[c.s.m.p.wizards?]
>But it doesn't work for unix. Nobody reads the group. c.s.m.p.wizards was
>hashed out here a while ago, and died because it's a worthless idea. Maybe
>you're new here.

I didn't know about this.  I've been reading c.s.m.p since late October,
1991.  While I wouldn't consider myself a newbie, I didn't know that it
had been tried before.  What went wrong?

Also, from the volume of postings I just saw (say 30 or so), it looks to me
like it does a good job of weeding out the chaff, while certainly not dead.
Anyway, I like the theory behind the idea.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Organization: University of Illinois at Urbana
Date: Sun, 19 Apr 1992 23:16:42 GMT

[e-mail] (Scott Bronson) writes:

>I use nn.  Too bad hardly anybody bothers to put good descriptive subject
>lines in their messages.  I usually just hilite all, then go through and
>remove the messages that I know that I don't want to read.  Wouldn't you
>agree that most of the manual work of selecting articles could be overcome
>by pre-sorting articles into their own newsgroups?

I cannot believe you do this. If I select more than 4 articles then
I'm *really* bored. If a poster can't be bothered to use a descriptive
subject line then I can't be bothered to read it. A generic line gets my
attention only if it's something I'm quite familiar with. But selecting
everything? Do you vote to split up all the other groups you read?
Followups are a problem, though, when the topic changes from the subject line.
But if I notice a lot of articles on one thread, I'll read it anyway (and then
remember to read it, or kill it. Killing reduces clutter substantially).

>I didn't know about this.  I've been reading c.s.m.p since late October,
>1991.  While I wouldn't consider myself a newbie, I didn't know that it
>had been tried before.  What went wrong?

Well, everyone will subscribe to it, since everyone want to be a wizard
eventually, and everyone will port to it, expecting a better response than
one from c.s.m.p.newbies. After all, if you're stumped you ask a wizard, right?
Especially if all the wizards have fled to the wizards group. Witness the
frequency of "How do you delete a file starting with -" postings in the unix
groups. You can't escape it. You have to start being selective in what you read.

Selectivity in what one reads is much preferable. It's a pity that nn
only fast newsreader around. All the Mac ones (even the non-HyperTrash ones)
are abysmally slow. NewsGrazer is bearable, just.
- --
Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 20 Apr 92 09:34:03 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Mark Lanett) writes:

   Selectivity in what one reads is much preferable. It's a pity that nn
   only fast newsreader around. All the Mac ones (even the non-HyperTrash ones)
   are abysmally slow. NewsGrazer is bearable, just.

I use GNUS, it's fast, and it's interactive. Unfortunately
it has no KILL file. But it does run on Macs (if you have
A/UX :^)

I think that, sooner or later, we will have to split c.s.m.p.
After a certain point, it just can't keep together anymore.

- --
"You should meet yourself someday. I'm sure you would hate it."
- - Me: [e-mail]; Jon W{tte (The Diplomat - NOT!)

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hanafee)
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
Date: Tue, 21 Apr 1992 22:43:15 GMT


In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>I use GNUS, it's fast, and it's interactive. Unfortunately
>it has no KILL file. But it does run on Macs (if you have
>A/UX :^)

Yes it does.  Try ESC-k (local kill file) or ESC-K (global kill file).
If that doesn't work, try a more recent version of GNUS.  I am using
version 3.13, NNTP 3.10.  (You can get your version number by typing
'V' in your newsgroups buffer.

- --
Brian Hanafee                         Advanced Decision Systems
[e-mail]                      1500 Plymouth Street
[phone]                        Mountain View, CA 94043-1230

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 21 Apr 92 19:08:30 GMT
Organization: MacDTS Mongols

In article <scott.703707281@mcl>, [e-mail] (Scott Bronson) writes:
> Nevertheless, I really like the idea of organizing this hierarchy better.
> If we figure out what we need by discussion here and it achieves popular
> appeal, it shouldn't be too hard to get the CFV to pass.

OK, a really simple suggestion would be to use the Subject lines in a more
constructive matter, either specify clearly the question, and if the thread
moves away, change the subject line.

Or then place tags in the Subject line itself, so that if someone asks
a question about QuickDraw, the Subject line would look like:

Subject: GRAPHICS - problems with DrawString

Similarly a question related to compilers would be:

Subject: TOOLS - How does Think C differ from C++

This requires that people creating the original posting would follow
these guidelines. Alas I have a feeling that this will not work in
practise. Maybe if we have enough monkies...


Cheers,
Kent

---------------------------

From: Chris Haynes <[e-mail]>
Subject: Quickdraw to ASCII printer
Organization: Computer Science, Indiana University
Date: Wed, 15 Apr 1992 13:22:30 -0500

I need to send ASCII characters straight out the printer port of a Classic
(from a MacScheme program, but that shouldn't matter). I'm told the best
way to do this is via Quickdraw calls using an appropriate driver (that
does *not* do bit map conversion).  Does anyone know how I can get such a
driver?

Thanks in advance for any tips.

Chris Haynes
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: 15 Apr 92 20:12:35 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] writes:
>I need to send ASCII characters straight out the printer port of a Classic
>(from a MacScheme program, but that shouldn't matter). I'm told the best
>way to do this is via Quickdraw calls using an appropriate driver (that
>does *not* do bit map conversion).  Does anyone know how I can get such a
>driver?

Whoever told you this was wrong.  The best way to do what you describe
is to use the serial driver (which does exactly as you ask).  I don't
know how to access that from MacScheme, though.



- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: Chris Haynes <[e-mail]>
Organization: Indiana University, Bloomington
Date: Thu, 16 Apr 1992 09:42:08 -0500

In article <[e-mail]> [e-mail] (Matthew T. Russotto) writes:
>In article <[e-mail]> [e-mail] writes:
>>I need to send ASCII characters straight out the printer port of a Classic
>>(from a MacScheme program, but that shouldn't matter). I'm told the best
>>way to do this is via Quickdraw calls using an appropriate driver (that
>>does *not* do bit map conversion).  Does anyone know how I can get such a
>>driver?
>
>Whoever told you this was wrong.  The best way to do what you describe
>is to use the serial driver (which does exactly as you ask).  I don't
>know how to access that from MacScheme, though.

An experienced Mac programmer tried writing a serial driver interface for
me, and got it working on an si, but it didn't work on the Classic.  He
(and others) have told me that due to the poor documentation and operating
system version dependence of the low level Mac interfaces, such as the
serial driver, it is better to use the high level Quickdraw call with the
appropriate printer abstraction, namely an ascii driver.  Writing such a
driver is a formidable task unless you are intimately familiar with the Mac
OS, but someone must have done it by now, yes?



+++++++++++++++++++++++++++

From: [e-mail] (Tony Wingo)
Date: 20 Apr 92 16:26:16 GMT
Organization: Apple Computer

In article <[e-mail]>, [e-mail] (Chris Haynes) writes:
>
> In article <[e-mail]> [e-mail] (Matthew T. Russotto) writes:
> >In article <[e-mail]> [e-mail] writes:
> >>I need to send ASCII characters straight out the printer port of a Classic
> >>(from a MacScheme program, but that shouldn't matter). I'm told the best
> >>way to do this is via Quickdraw calls using an appropriate driver (that
> >>does *not* do bit map conversion).  Does anyone know how I can get such a
> >>driver?
> >
> >Whoever told you this was wrong.  The best way to do what you describe
> >is to use the serial driver (which does exactly as you ask).  I don't
> >know how to access that from MacScheme, though.
>
> An experienced Mac programmer tried writing a serial driver interface for
> me, and got it working on an si, but it didn't work on the Classic.  He
> (and others) have told me that due to the poor documentation and operating
> system version dependence of the low level Mac interfaces, such as the
> serial driver, it is better to use the high level Quickdraw call with the
> appropriate printer abstraction, namely an ascii driver.  Writing such a
> driver is a formidable task unless you are intimately familiar with the Mac
> OS, but someone must have done it by now, yes?
>
He couldn't have been that experienced.  While I admit that the serial driver
documentation is scattered accross three volumes of IM and half a dozen tech
notes, everything you need to know for an application of this sort is there.

If you RTFM, and especially read all the relevent tech notes, you can write
a serial interface that runs across all the platforms.  I know.  I've done it
several times for several companies.

The fact that he is trying to pawn off a mythical beast (an "ASCII Quickdraw
driver" ) on you also says a lot for his level of experience.

Find another Mac Programmer.

- -tony

>>usual disclaimers apply<<


---------------------------

Subject: Need help with Finder AppleEvents...
From: [e-mail] (Roby Sherman)
Date: 15 Apr 1992 22:56:09 -0400
Organization: The Tao of Programming

Hi.

I am trying to put together a small pascal program that will send an "SOPE"
(Open Selection) Apple Event to the Finder. My program sends off the Apple
Event but nothing happens, which leads me to believe that I've done
something wrong as usual. ;-)  My only reference has been the "Finder
Events" stack off of FTP.APPLE.COM which is written far too topsy-turby for
me... I am looking for a very simple C or Pascal piece of code that
demonstrates how to put together and X-mit this Apple Event to the Finder.

              Thanks in advance...

                Roby

- --
[e-mail]                    Roby Sherman

+++++++++++++++++++++++++++

From: [e-mail] (Jack Littleton)
Date: 17 Apr 92 01:03:35 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Roby Sherman) writes:
>Hi.
>
>I am trying to put together a small pascal program that will send an "SOPE"
>(Open Selection) Apple Event to the Finder. My program sends off the Apple
>Event but nothing happens, which leads me to believe that I've done
>something wrong as usual. ;-)

Here are a couple "trivial" thoughts about this...Be sure that you're using
'sope' as the event ID, and not 'SOPE'.  The Apple Event Manager is case
sensitive, even though you're using a non-case sensitive language.

The second trivial thought deals with what you're trying to open.  If you're
trying to open an application, dump the Apple Event approact and go with the
Process Manager's LaunchApplication routine.  It's much more straightforward.

Hope this helps somewhat...

Jack Littleton
Developer Tools Engineering
Apple Computer, Inc.

*Opinions expressed here are not necesarily those of Apple Computer, Inc.*


- --
Jack Littleton                Internet: [e-mail]
MPW Compiler/Linker group     AppleLink: JACINTOSH
Apple Computer, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 20 Apr 92 21:16:19 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Roby Sherman) writes:
> My only reference has been the "Finder
> Events" stack off of FTP.APPLE.COM which is written far too topsy-turby for
> me

Hey, I resemble that remark!  ;)

That's the problem with kitchen sink code.  The more it does, the less
clearly it does it.  I didn't feel like writing 25 smaller XCMDs though.

Maybe I'll write a simpler open only XCMD.  Maybe I won't.  ;)

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Roby Sherman)
Date: 21 Apr 1992 09:07:28 -0400
Organization: The Tao of Programming

In <[e-mail]> [e-mail] (Jon Pugh) writes:

>Hey, I resemble that remark!  ;)

Well, ok, it wasn't THAT topsy-turby! ;-)


>That's the problem with kitchen sink code.  The more it does, the less
>clearly it does it.  I didn't feel like writing 25 smaller XCMDs though.

Well, What I ended up doing was making sort of a "run-time Hypercard XCMD"
that I could step through and see which routines I needed and which ones I
could throw away. I ended up chucking all of the procedures and functions
except for finderevents itself, and modifying it so you can pass it a
pathname and a Filename...

Doesn't mean I UNDERSTAND it all that well, but at least it works. <grin>


                thanks,

                     Roby
- --
[e-mail]                    Roby Sherman

---------------------------

End of C.S.M.P. Digest
**********************